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BACKGROUND OF THE INVENTION 


1. Technical Field 

The present invention relates to a method for improving commu- 
10 nications between senders and receivers via a network, such as 
servers, routers, and clients communicating via the Internet 
comprising routers by extending signaling messages of a proto- 
col used for the network and a communication system operated 
by the method according to the invention. 

15 

2. Background of the Invention 

The Resource Reservation Protocol (RSVP) is specified by the 
Internet Engineering Task Force (IETF) and used to provide the 

20 signaling to enable network resource reservations and alloca- 
tions to provide Integrated Services. In particular, RSVP en- 
ables Guaranteed Services and Controlled-Load Services. In 
this manner it is possible, for example, to obtain a control 
and guarantee of load for network resources/components, such 

25 as network domains, servers, clients, routers, and communica- 
tion links. Resources are reserved or allocated for unidirec- 
tional data flows. A detailed description of the RSVP can be 
found in the article "RSVP and Integrated Services in the 
Internet: A Tutorial" by P. P. White in IEEE communications 

30 Magazine, May 1997, p. 100. 

In RSVP the server sends a PATH -message to the client, con- 
taining a traffic specification (upper and lower bounds of 
bandwidth, delay and jitter). This message is used to store 
35 the path state in each node (e.g. router) to route Reserva- 
tion-Request- (RESV) -messages in the reverse direction. On the 
way of the RESV-message to the client, each network checks the 
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traffic specification and possibly filters the requirements 
according to the network capabilities and resource availabil- 
ity (admission control) . The traffic specification is received 
by the client, upon which the client returns a RESV-message to 
the server to reserve the resources between the client and the 
server . 

Since most traffic requiring reservations is delivered to 
groups (e.g. TV), it is natural for the client to make the re- 
quest for a reservation for a flow. This has the added advan- 
tage that different clients can make heterogeneous requests 
for capacity from the same source. 

The primary roles of the PATH-message are first to install re- 
verse routing state in each router of the network along the 
communications path, and second to provide clients with infor- 
mation about the traffic characteristics of the sender and 
end-to-end (sender-client) communications path to generate ap- 
propriate reservation/allocation requests. The primary role of 
the RESV-message is to carry reservation/allocation requests 
to routers of the network along the distribution tree between 
clients and senders, wherein the distribution tree can also be 
a connection between one server and one client. 

Fig. 1 provides a (simplified) overview of the RSVP signalling 
messages flows and the most important parameters in each of 
the messages. 


The most relevant information in the PATH-message is the TSPEC 
of the sender defining the sender traffic characteristics. 

The ADSPEC is an optional object that the server may include 
in its generated PATH-messages in order to provide the clients 
with the characteristics of the end-to-end communications 
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path. This information can be used by clients to determine the 
level of reservation required in order to achieve their de- 
sired end-to-end QoS. The parameters included in the ADSPEC 
may be updated at each RSVP-Capable router along the path in 
5 order to present end-to-end values to the clients- Some of the 
parameters are e.g. the minimum path latency, summation of in- 
dividual link latencies, the path bandwidth, and the minimum 
of individual link bandwidths along the path- 

10 RSVP supports both unicast and multicast sessions. The flow 
descriptors specify the QoS, which is used by participating 
entities, such as routers, server and clients. Hosts use RSVP 
to request a QoS level from the network on behalf of an appli- 
. cation data stream. Routers use RSVP to deliver QoS requests 

15 to other routers along the path(s) of the data stream. RSVP is 
able to adapt to changes in routing. 

A simplified overview of the operation of the RSVP is given in 
the following. 

20 

Servers characterize outgoing traffic in terms of upper and 
lower bounds of bandwith, delay, and jitter. RSVP sends a 
PATH-message from the server that contains this traffic speci- 
fication (TSPEC) information to the destination address (uni- 

25 cast or multicast receivers) . At reception of a PATH-message 
an RSVP capable router creates a PATH-state and stores the 
last hop address from the PATH-message and the TSPEC- 
information in the PATH-state. The last hop address is used 
for the routing of the RESV-message afterwards. Additionally, 

30 RSVP capable routers may update the ADSPEC-inf ormation to con- 
tain end-to-end relevant parameter values. 

To make a resource reservation/allocation, clients send a 
RESV- (reservation request) -message upstream. In addition to 
35 the TSPEC, the RESV message includes a request specification 
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(RSPEC) that indicates the type of integrated services re- 
quired and a filter specification (FilterSPEC) , that charac- 
terizes the data packets for which the reservation is being 
made. (e.g. the transport protocol and port number) . Together, 
5 the RSPEC and FilterSPEC represent a flow-descriptor that 
routers use to identify each reservation. 

/ 

When each RSVP router along the upstream path receives the 
RESV-message, it uses the admission control to authenticate 

10 the request and allocate the necessary resources. If the re- 
quest cannot be satisfied (due to lack of resources or 
authorization failure) , the router returns an error back to 
the client. If accepted, the router sends the RESV upstream to 
the next router. When the last router receives the RESV and 

15 accepts the request, it sends a confirmation message back to 
the client. There is an explicit tear-down process for a res- 
ervation when a sender or receiver ends an RSVP session. 

Token Bucket Metaphor 

20 RSVP is based on the token bucket metaphor, which turns an un- 
even flow of packets from the user processes inside the host 
into an even flow of packets onto the network, smoothing out 
bursts and greatly reducing the chances of congestion. In this 
manner, a controlled load can be provided throughout the net- 

25 work . 

Token bucket related parameters, which are to be defined for 
the TSPEC-inf ormation, include peak rate of flow (bytes/s), 
bucket depth (bytes) , token bucket rate (bytes/s) , minimum po- 
30 liced unit (bytes) , and maximum datagram size (bytes) . 

RSVP and Integrated Services 

RSVP enables so-called Integrated Services, of which there are 
two fundamentally different types: 
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Guaranteed Services: A guaranteed service comes as close as 
possible to emulating a dedicated virtual circuit. It provides 
firm (mathematically provable) bounds on end-to-end queuing 
delays by combining the parameters from the various network 
elements in a path, in addition to ensuring bandwidth avail- 
ability according to the traffic specification parameter in 
the PATH-message. 

Control led-Load Services: A control led-load service is equiva- 
lent to "best effort service under unloaded conditions". 

Integrated services uses a token-bucket model to characterise 
its input/output queuing algorithm. This is, as an example, 
beneficial in case of a variable bit-rate video codec. The to- 
ken-bucket parameters "bucket rate", "bucket depth", and "peak 
rate" are part of the TSPEC- and RSPEC-inf ormat ion . 

RSVP provides the highest level of Internet Protocol Quality 
of Service (IP-QoS) available. It allows an application to re- 
quest QoS with a high level of granularity and with the best 
guarantees of service delivery possible. However, the price 
for this is the complexity and overhead, and thus is overkill 
for many applications. 

Multicasting 

Multicast is the efficient transmission of an Internet Proto- 
col (IP) datagram to a set of zero or more hosts identified by 
a single IP destination address. 

IP multicast efficiently supports one-to-many and many-to-many 
transmission by enabling sources to send a single copy of a 
message to multiple recipients (indirectly identified by a 
single IP class-D multicast address) who explicitly want to 
receive the information. This mechanism is far more efficient 
than sending multiple messages to each recipient simultane- 
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ously or broadcasting the message to all nodes on the network. 
IP multicasting is a natural solution for multi-party 
conferencing because of the efficiency of the data distribu- 
tion trees (spanning trees) , with data being replicated in the 
network at appropriate points rather than in end-systems. 

Multicasting is based on a series of specific protocols that 
"ride on top" of the existing ones to efficiently distribute 
data to all interested parties. With IP multicast clients do 
not need to know who or where the servers are to receive traf- 
fic from them. Servers never need to know who the clients are. 
Neither servers nor clients need to care about the network to- 
pology as the network optimizes delivery. 

Multicast is a receiver-based concept. Receivers join a par- 
ticular multicast session group by informing the multicast 
router on their subnetwork (Internet Group Management Proto- 
col, IGMP) and traffic is delivered to all members of that 
group by the network infrastructure. For delivery of a multi- 
cast packet from the source (sender, server) to the destina- 
tion nodes on other networks, multicast routers need to ex- 
change the information they have gathered from the group mem- 
bership of the hosts directly connected to them. There are 
many different algorithms and protocols to exchange this rout- 
ing information, such as Distance Vector Multicast Routing 
Protocol (DVMRP) , Multicast extension to OSPF (MOSPF) , and 
Protocol Independent Multicast (PIM) . Based on the routing in- 
formation obtained through one of these protocols, whenever a 
multicast packet is sent out to a multicast group, multicast 
routers will decide whether to forward that packet to their 
network (s) or not. Finally, the leaf router will see if there 
is any member of that particular group on its physically at- 
tached networks based on the IGMP information and decides 
whether to forward the packet or not. 
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If the sender layers its data (e.g. video or audio) stream, 
different receivers can choose to receive different amounts of 
traffic and hence different qualities. To do this the sender 
must code the data (e.g. video data) as a base layer having 
5 the lowest quality being acceptable and a number of enhance- 
ment layers, each of which adds more quality at the expense of 
more bandwidth. With video, these additional layers might in- 
crease the framerate or increase the spatial resolution of the 
images or both. Each layer is sent to a different multicast 
10 group and receivers thereof can individually decide how many 
layers to subscribe to. 

Fig. 2 shows an IP multicast scenario where a video stream is 
sent to four recipients (i.e. clients 1, 2, 3 and 4). Clients 
1 and 2 have joined the group by informing multicast router R2 
and clients 3 and 4 have done the same with multicast router 
R3. Client 1 receives a base layer (white packets), e.g. a 
code optimized for wireless environments, whereas client 2 re- 
ceives this base layer and an additional layer (gray packets) 
for a better video quality. Clients 3 and 4 receive a differ- 
ent base layer (e.g. a wireline codec) . 

To achieve an efficient transmission, a spanning tree is con- 
structed, that connects all members of the multicast group. 
Only one copy of a multicast message will pass over any link 
in the network between the sender (server) and multicast 
router Rl. Copies of the message will be made only where paths 
diverge at a router (here at routers Rl , R2 and R3). Note that 
the "merging" of multicast streams at traffic replication 
points (such as Rl, R2 and R3) involves complex algorithms. 

RSVP and Multicasting 

RSVP may be used for multicast transmission. The RSVP PATH 
message will follow exactly the same path as the stream itself 
35 also for multicast transmission. 
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Fig. 3 shows the multicasting of the PATH message. The routers 
Rl, R2, and R3 have multicasting and RSVP capabilities. 

5 The sender periodically sends a PATH message for each data 
flow it originates. 

The RESV-message is sent by the recipients (clients l, 2, 3, 
and 4) of the stream towards the source following the exact 
10 inverse path of the PATH-message. The stream itself is charac- 
terized by a filter, so a single reservation can apply to sev- 
eral streams (e.g. several sources in a conference), i.e. a 
shared reservation. This is reflected in Fig. 4. 

Fig. 4 shows that multiple reservations for a multicast stream 
can be merged. If, for example, client 3 requires a low delay 
and client 4 is prepared to cope with more delay for the same 
multicast stream, then only the largest reservation (i.e. low- 
est delay) will be forwarded upstream (i.e. from R3 to Rl) . 
The same applies in case e.g. client 3 wants to receive the 
base layer for a specific video codec, whereas client 4 wants 
to receive the base and an additional layer. 

At branch points (i.e. the routers Rl, R2, R3) in the distri- 
25 bution tree (to be) reserved TSPECs of the branches are not 

the same. The (to be) reserved TSPEC of a branch closer to the 
server is given by the maximum of the (to be) reserved TSPECS 
of its direct successors (in the direction of the destina- 
tion) . 

30 Differentiated Services 

Differentiated Services (DiffServ) provide mailings within IP 
packet leaders to allow prioritization of traffic aggregates 
(i.e. "classes" of multiple flows). DiffServ is employed to 
design a simple architectural framework for QoS that can pro- 
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vide a variety of scalable end-to-end services access multiple 
separately administered domains with requiring complex inter- 
provide business arrangements or complex behaviors in forward- 
ing equipment. 

5 Bandwidth Brokers 

A Bandwidth Broker maintains information relating to SLSes 
that are defined between a DiffServ domain and its customers, 
where DiffServ domain denotes a region of shared trust, ad- 
ministration, provisioning, etc. Customers include local users 

10 as well as the adjacent networks that provide connectivity to 
other parts of e.g. the Internet. The internals of a DiffServ 
domain are not relevant to its customers, as long as the ex- 
ternal obligations are fulfilled. The Bandwidth Broker uses 
this SLS information to configure routers in the local Diff- 

15 Serv domain (mainly the edge routers) , and to make admission 
control decisions. The Bandwidth Broker is required to keep 
track of QoS resources, make policy decisions based on SLS in- 
formation, and communicate policy enforcement information to 
the edge devices within the DiffServ domain. Furthermore, the 

20 bandwidth broker establishes and maintains SLAs with neigh- 
bouring domains. 

The general idea is for a customer to buy from their provider 
a profile for higher quality service, and the provider polices 
25 marked traffic from the site to ensure that the profile is not 
exceeded. Where providers peer, they arrange for an aggregate 
higher-quality profile to be provided, and police each other's 
aggregate if it exceeds the profile. 

30 In this way, policing only needs to be performed at the edges 
to a provider's network based on the assumption that within 
the network there is sufficient capacity to cope with the 
amount of higher-quality traffic that has been sold. 
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Before marked packets (DiffServ) from a data source are admit- 
ted to a Diffserv domain, the source must signal its local 
Bandwidth Broker to initiate a service reservation. The poten- 
tial source is authenticated and subjected to local admission 
5 control policies. If the service reservation is admitted lo- 
cally, the Bandwidth Broker may initiate an end-to-end reser- 
vation request along the chain of Bandwidth Brokers in the 
DiffServ networks to be traversed by the data flow. When a 
network-wide admission control decision has been made, the 

10 Bandwidth Broker will configure the routers in the DiffServ 

domain to support the requested service profile. The Bandwidth 
Broker allows separately administered DiffServ domains to man- 
age their network resources independently, yet still cooperate 
with other domains to provide dynamically allocated end-to-end 

15 QoS. 

Problems 

Currently, RSVP supports limited communication/ service quality 
negotiations between servers and clients. Only the resulting 

20 end-to-end bandwidth and ADSPEC-inf ormation related data are 
provided to the clients. This information may be used by the 
clients to verify whether they would like to use the service 
with the indicated service quality characteristics. Other 
service quality characteristics, such as security, reliabil- 

25 ity, and actual jitter are missing and therefore not taken 

into account for the service quality negotiation. Such service 
quality characteristics are missing from the ADSPEC- 
information and are thus not updated on the way from the 
server to the client (s) . As mentioned above, jitter informa- 

30 tion is implicitly included in the PATH-message , in particular 
in the token bucket parameters, but any changes thereof are 
not considered. 
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Moreover, no mechanisms are currently available to efficiently 
collect information about the network domains (and clients) 
between the server (s) and client (s) . 

5 Since no mechanism for information collection is available, 
there is also no mechanism to handle this in a more efficient 
way in case of multicasting for one-to-many or many-to-many 
service provisioning. Further, a service quality optimization 
with respect to high(er) priority clients or servers is not 
10 available. 

Further, no mechanism exists to limit the number of wasted re- 
source allocations in case of multicasting. 

15 In order to overcome the existing problems of the prior art, 
the object of the present invention is to provide a solution 
for improving communications in a network utilizing a resource 
reservation protocol, such as the RSVP. 

20 BRIEF DESCRIPTION OF THE INVENTION 

The basic idea of this invention is to collect information by 
extending the signaling messages in a protocol like the RSVP. 
Information is collected throughout the network, e.g. from all 

25 network domains and/or subnetworks, between servers and corre- 
sponding client (s). Any network component serving as a sender, 
e.g. servers, notes, routers, may use the collected informa- 
tion to check the actual status of the network, to make serv- 
ice distribution decisions, to make service provisioning deci- 

30 sions (e.g. links in a proxy or gateway) , etc. RSVP is just an 
example for a protocol for which the present invention can be 
utilized. Therefore, the mechanisms according to the invention 
described here can be applied to similar or comparable proto- 
cols . 

35 
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The present invention optionally extends negotiation informa- 
tion between a server and respective clients which can be used 
by clients to decide on the acceptance of an overall service 
provisioning quality. 

5 

In addition to an information collection for a single-client 
case, the present invention is also applicable for multi- 
client cases wherein multicasting and/or aggregation of col- 
lected information is utilized. 

10 

Moreover, a pre-reservation mechanism provided by the present 
invention can be implemented to prevent wasted resource allo- 
cations and extensive signaling in case of multicasting and/or 
to improve the quality of service for high priority clients. 

15 

Thus, the present invention addresses an information collec- 
tion mechanism, quality of service negotiations between a 
server and its client(s), and a pre-reservation mechanism of 
network resources, for single-client and/or multi-client ap- 
20 plications, wherein in the case of a multi-client application 
multicasting and/or aggregation of collected information is 
possible . 

To achieve the underlying object, the present invention pro- 
25 vides a method for improving resource reservations and alloca- 
tions in a network operated by a given signaling message pro- 
tocol, e.g. the RSVP. According to the given protocol, a 
sender signal including sender traffic characteristics infor- 
mation of a sender is generated and transmitted via at least 
30 one network. According to the invention, network traffic char- 
acteristics information is included into the sender signal 
while being transmitted to obtain an extended sender signal. 
The network traffic characteristics information is indicative 
of traffic characteristics of the network. Further, network 
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resources are reserved and/or allocated in dependence of the 
network traffic characteristics information. 

Furthermore, it is possible to receive the extended sender 
5 signal by a receiver and to generate, in response thereto, a 
receiver signal according to the given protocol including re- 
ceiver traffic characteristics information being indicative of 
traffic characteristics of the receiver. Additionally, the 
network traffic characteristics information is included into 
10 the receiver signal to obtain an extended receiver signal. As 
a result, network resources can be reserved and/or allocated 
in dependence of the network traffic characteristics informa- 
tion and the receiver traffic characteristics information. 

15 In order to further improve service quality negotiations, it 
is possible to transmit the extended receiver signal to the 
sender, while updating the extended receiver signal by includ- 
ing actual network traffic characteristics information during 
transmission. As a result, network resources can be allocated 

20 in dependence of the updated extended receiver signal. 

It is preferred to transmit the extended sender signal and/or 
the extended receiver signal and/or the updated extended re- 
ceiver signal via at least one router and to include and/or 
25 update the network traffics characteristics information by in- 
cluding and/or updating information being indicative of traf- 
fic characteristics of the at least one router. 

The reservation and/ or allocation of network resources can 
30 also be performed by the sender in dependence from the signal 
received from the at least one network, and/or the receiver in 
dependence of the received extended sender signal, and/or the 
at least one router in dependence of the received signal re- 
ceived from the network. 


35 
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To implement a pre-reservation and/or pre-allocation mecha- 
nism, reservation and/or allocation information is included 
into the sender signal according to the given protocol. The 
reservation and/or allocation information is indicative of 
network resources to be pre-reserved and/or pre-allocated . 
Thus, it is possible to pre-reserve and/or pre-allocate net- 
work resources in dependence of the reservation and/or alloca- 
tion information. 


10 Improved network information can be obtained by including ac- 
tual reservation and/or allocation information into the ex- 
tended sender signal including the reservation and/or alloca- 
tion information, the actual reservation and/or allocation in- 
formation being indicative of network resources actually pre- 

15 reserved and/or pre-allocated. 


In this case, it is preferred that the at least one router re- 
serves and/or allocates available resources thereof in depend- 
ence of the reservation and/or allocation information of the 
20 sender and includes the actual reservation and/or allocation 
information corresponding to the actually pre-reserved and/or 
pre-allocated router resources. 


For a client oriented resource reservation and/or allocation, 
25 the receiver includes a reservation and/ or allocation request 
into the extended receiver signal in dependence of the re- 
ceived actual reservation and/or allocation information. Here, 
the reservation and/or allocation request is indicative of 
network resources to be used for communication with the 
30 sender. 


As a result, it is possible to reserve and/or allocate network 
resources in dependence of the reservation and/or allocation 
request in the extended receiver signal and/or the updated ex- 
35 tended receiver signal. 
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If routers are employed, the at least one router can reserve 
and/or allocate pre-reserved and/or pre-allocated router re- 
sources in dependence of the reservation and/or allocation re- 
5 quest in the signal transmitted from the receiver. 

As a further option, indicators being indicative of resource 
reservations and/or allocations can be included in the signals 
transmitted via the network (e.g. in the sender signal, the 

10 extended sender signal and/or the extended receiver signal) . 
Here, it is possible to use an indicator with respect to at 
least one of the network resources whether a resource reserva- 
tion and/or resource allocation is performed for signals 
transmitted downstream to clients (e.g. (extended) sender sig- 

15 nal) and/or for signals transmitted upstream to senders (e.g. 
an extended receiver signal) . Since some of the pre-reserved 
and/or pre-allocated resources in response to signals trans- 
mitted downstream to clients may be released upon a reception 
of related signals transmitted upstream to senders, such re- 

20 sources may be pre-reserved and/ or pre-allocated in dependence 
of higher priority resource reservation and/or allocation re- 
quests. Therefore, (extended) sender signals including reser- 
vation and/or allocation information can include "minimum re- 
source required" indicators. Resources exceeding this minimum 

25 resources can optionally be used with respect to reservations 
and/or allocations by higher priority resource requests. As a 
result, a faster connection setup for transmissions in the 
network can be obtained, since respective resources have al- 
ready been pre-reserved and/or pre-allocated. 

30 

In order to avoid unnecessary use of network resources, pre- 
reserved and/or pre-allocated network resources exceeding the 
reservation and/or allocation request of the receiver are re- 
leased. Here, it is possible that the at least one router re- 
35 leases its pre-reserved and/ or pre-allocated resources in de- 
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pendence of the reservation and/or allocation request in the 
signal transmitted from the receiver. 

However, signals transmitted upstream from the receiver (e.g. 
5 (extended) receiver signals) can specify that all" pre-reserved 
and/or pre-allocated resources remain reserved and/or allo- 
cated, or that a maximum or a minimum thereof remains reserved 
and/or allocated. This procedure still leads to an improved 
quality of service and in particular provides a fast connec- 
10 tion setup. 


Moreover, the present invention provides network system util- 
izing a given signaling message protocol for network resource 
reservations and allocations, a sender, a receiver, and/or at 
15 least one network for connecting the sender and the receiver 
are operated by one of the methods according to the invention. 

BRIEF DESCRIPTION OF THE FIGURES 


20 


25 


30 


In the following description of preferred embodiments, it is 
referred to the accompanying figures wherein: 

Fig. 1 shows RSVP signaling messages and parameters thereof, 

Fig. 2 illustrates an IP multicasting network, 

Fig. 3 illustrates a PATH-message multicasting in a RSVP 
network, 

Fig. 4 illustrates a RESV-message inverse multicasting in 
the RSVP network of Fig. 3, 

Fig. 5 illustrates a network utilizing RSVP-mes sages ex- 
tended according to the invention, 
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Fig. 6 illustrates a RSVP network utilizing RESV— messages 

extended according to the invention for inverse mul- 
ticasting, and 

5 Fig. 7 illustrates a pre-reservation mechanism according to 
the invention in a RSVP network. 

DESCRIPTION OF PREFERRED EMBODIMENTS 

10 

As described above, senders, receivers, and communication 
means (routers) for routing communications between the senders 
and the receivers in a network utilize reservation protocols 
in order to set up the necessary network state and to support 

15 communications and associated services between the senders and 
receivers, one example for such a reservation protocol is the 
resource reservation protocol (RSVP) . The following embodi- 
ments are set forth with respect to the RSVP, however the un- 
derlying principle is suitable to improve other network reser- 

20 vation protocols, e.g. ST-II. 

Basic embodiment 

In order to improve service quality negotiations between ser- 
vers and clients communicating via a network utilizing the 

25 RSVP, the signaling messages of the RSVP, namely the PATH- 

messages and the RESV-messages , are extended/modified to in- 
clude further information being indicative of the actual 
status of the network and its network domains, respectively. 
This information is collected from all parts of the network 

30 used for communication between a server and a client. In addi- 
tion to the information collected for all respective network 
domains, it is contemplated that this information also in- 
cludes information being indicative of the actual status of a 
server and its client(s). 

35 
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On the basis of the collected information, the server, the 
client (s) and routers of the network and/or network domains 
are enabled to check the actual status of the network and/or 
its domains, to control the distribution of services provided 
5 via the network, to control the provisioning of network serv- 
ices (e.g. links to a proxy or gateway), to perform service 
quality negotiations between the server and its client (s), and 
to pre-reserve/pre-allocate communication resources of the 
network. Such a procedure can be applied to both single-client 
10 and multi-client applications, wherein for the latter case 
multicasting and/or an aggregation of the collected informa- 
tion is an additional option. 

Referring to a PATH-message of the RSVP, the traffic specif i- 
15 cation (TSPEC) thereof defining the traffic characteristics of 
a server is extended by information characterizing the actual 
traffic characteristic of the network, and in particular of 
the network domains between the server and its client (s) and 
their routers, respectively. Further, the TSPEC can be ex- 
20 tended by traffic characteristics information of the client. 
It has to be emphasised, that the TSPEC itself is not modi- 
fied. 


The traffic characteristics information of the network and the 
25 client can be provided as information directly identifying the 
respective traffic characteristics. As an alternative, the 
traffic characteristic information of the network and the cli- 
ent can represent variations of the actual traffic character- 
istics of the network and the client with respect to previous 
30 traffic characteristics thereof. Such variations can be caused 
by a variation of communications resources of the network or 
the client, wherein such resource variations include an in- 
creased and a decreased resource availability, in particular, 
these variations can relate to previous traffic characteris- 
35 tics of same network components (e.g. network domains, 
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routers, servers, clients, gateways, etc.) and/or to traffic 
characteristics of previous network components, i.e. network 
components located more upstream with respect to the direction 
of data communication. 

5 

In general, messages of the RSVP are generated by each network 
component (server, client, router) on the basis of a received 
message for forwarding the information thereof. Therefore, 
PATH-messages extended as explained above can include either 
10 above type of traffic characteristics information of the net- 
work and the client (s) depending on the network component 
(server, router, client) forwarding the respective PATH- 
message . 

15 Further, ADSPEC-inf ormation of the PATH-message can be ex- 
tended by other communication characteristics, such as secu- 
rity, reliability, and jitter information. Comparable to the 
above traffic characteristics information, such further commu- 
nication characteristics information are added to the ADSPEC- 

20 information of the server by the routers and the client (s) . 
Again, the ADSPEC-inf ormation itself is not changed. 

In order to access the actual communications state of the net- 
work and the client (s) , the traffic characteristics informa- 

25 tion collected while forwarding the PATH-message are added to 
the RESV-message returned from the client (s) to the server. In 
particular, the collected traffic characteristics information 
is added to the RESV-message according to the RSVP to extend 
the TSPEC thereof. An improved communication quality negotia- 

30 tion between the server and its client (s) can be achieved by 
further extending the TSPEC of the RESV-message with informa- 
tion being indicative of the resulting end-to-end communica- 
tion characteristics. Receiving such an extended RESV-message, 
the server obtains substantial information of the actual com- 

35 munications status and is enabled to adapt its communications 
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(distribution) correspondingly, e.g. by modifying the distri- 
bution of provided services. 

Since the client (s) is (are) also provided with information 
being indicative of the actual communications status of the 
network and, in addition, of the server, the respective RESV- 
message can be generated considering the received communica- 
tions status information. If, for example, a client determines 
that the over-all communication quality (quality of service) 
is not acceptable, the RESV-message will not be returned and 
thus no resource allocation for the respective communication 
path between the client and the server is performed. 

Further, a service reject by the client can include informa- 
tion indicative of reasons for the service reject. In re- 
sponse, the server can use such information for e.g. traffic 
engineering and/or network planning purposes. 

Moreover, as a further option, the RSPEC-inf ormation and/or 
the FilterSPEC-information of the RESV-message communicated to 
the server can be extended by further information being in- 
dicative of the communication (quality) characteristics in a 
manner comparable to the ADSPEC-inf ormation of the PATH- 
message . 

Traffic characteristics information collection for a network 
domain serving a single client 

For the purpose of simplicity, the embodiment shown in Fig. 5 
utilizes RSVP-messages only including respective TSPEC- 
inf ormation . 

As shown in Fig. 5, a communication path between a server and 
a client is routed via routers Rl and R2 constituing the net- 
work domain serving the client. The server generates a PATH- 
message according to the RSVP and transmits the same to the 
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router Rl. In order to indicate the type of mechanism, which 
is used or which is to be used, the PATH-message can be ex- 
tended accordingly. 

5 In response thereto, the router Rl processes the received 

PATH-message according to the RSVP. Assuming this processing 
results in a validity for the received PATH-message, the 
router Rl generates a conventional PATH-message including, ac- 
cording to the RSVP, the traffic characteristics provided by 
10 the server and updated routing information. Here it is pointed 
out, that this conventional PATH-message does not include any 
information representing the actual traffic characteristics of 
the network, so far. 

15 Further, the router Rl generates information which represent 
its actual traffic characteristics. Such information can in- 
clude the maximal /average peak rate of flow, the available 
bandwidth, the actual delay, the actual jitter, the actual se- 
curity level for data communications, actual allocated re- 

20 sources, available buffer space, and the like. This traffic 
characteristics information of the router Rl is added to its 
conventional PATH-message such said a message PATH' is ob- 
tained . 

25 The PATH » -message is transmitted to the router R2 which gener- 
ates, in response thereto, a message PATH ' ' in a manner compa- 
rable to the generation of the PATH ' -message . 

The PATH 1 ' -message transmitted from the router R2 is received 
30 by the client. In case, the processing of the PATH ' ' —message 
by the client is indicative of a communication/service quality 
being not acceptable for client, the client generates no RESV- 
message. 
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In case, the PATH 1 1 -message is indicative of a communica- 
tions/service quality being acceptable for the client, the 
client generates a RESV* -message. The RESV* -message comprises 
a conventional RESV-message according to the RSVP and, fur- 
5 ther, the collected traffic characteristics information. In 

addition, the RESV* -message can include information represent- 
ing the end-to-end characteristics calculated for the communi- 
cations between the server and the client performed so far. 

10 As a further option, it is possible that the RESV* • -message 
received by the router R2 is extended by its actual traffic 
characteristics information and transferred as a RESV* ' - 
message to the router Rl. Comparable, the RESV* 1 -message is 
extended by the router Rl and transferred as a message 

15 RESV ' '-message to the server. 

On the basis of the received RESV*' '-message, the server is 
enabled to access the actual communications status of the net- 
work domain serving the client. It is pointed out that this 
collection of traffic characteristics information can be per- 
formed when a communications/service is to be provided to the 
client, or can be just used to collect such information with- 
out providing communications/ services . In order to inform the 
routers Rl, R2 and/or the client whether the collection of 
traffic characteristics information is performed prior to the 
provision of communications/services or just for an assessment 
of the actual network status, the server can transmit a re- 
spective information, e.g. an indicator. 

30 Multicasting; aggregation 

In order to provide communications/services between one or 
several servers and several clients, the above described mul- 
ticasting is used for the message distribution. For the col- 
lection of traffic characteristics information, the PATH- 

35 messages from the server (s) and the routers of the (respec- 
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tive) network domain (s) are extended as set forth above for 
the single client case. Therefore, the respective extended 
PATH-messages from the server to the clients 1, 2, 3 and 4 are 
not shown in Fig 6 . 

5 

As explained above, the RESV-message received by a server for 
a conventional RSVP multicasting comprises aggregated RESV- 
messages from the respective clients. This aggregation serves 
to merge multiple reservations from several clients for a mul- 
10 ticast stream. 

In order to obtain a RESV*-message (i.e. a RESV-message ex- 
tended by traffic characteristics information) , an aggregation 
step is performed to provide the traffic characteristics in- 
15 formation of the network domains serving the clients 1, 2, 3 
and 4 and the resulting communications/service quality for 
each end-to-end (server-client) connection. 

Assuming that the traffic characteristics of the connections 
20 (networks) between the router R2 and the client 1, and the 

router R2 and the client 2 are the same, information being in- 
dicative of these traffic characteristics only need to be com- 
municated to the server once. As a result, the RESV*} 2 ' ~ 
message communicated from the router R2 to the router Rl only 
25 contains traffic characteristics information of the client 1 
provided by the RESV^-message, the traffic characteristics 
information of the client 2 provided by the RESV* 2 -m e ssage 
and, just once, traffic characteristics information related to 
the network domain comprising the router R2 , and the clients 1 
30 and 2 . 

In case the traffic characteristics of the networks between 
the router R2 and the client 1, and the router R2 and the cli- 
ent 2 are not the same, or in case the clients 1 and 2 are not 
35 comprised by the same network domain, the router R2 must de- 
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termine the overlap of the respective traffic characteristics 
information and aggregate the traffic characteristics informa- 
tion accordingly. As an alternative, router R2 can also just 
select e.g. the traffic characteristics which are received 
first. 

This aggregation step is accordingly performed with respect to 
the router R3 and the router Rl, respectively, wherein the 
transmitted RESV* • 3 , 4 -message and the RESV* '1,2,3, 4 -message 
are extended by the respective traffic characteristics infor- 
mation of the network domains including routers Rl and R3 . 

As a result, the RESV* ' ' 1 , 2 , 3 , 4 -message received by the 
server can only comprise, beside the traffic characteristics 
information of the clients 1, 2, 3 and 4 and the routers Rl, 
R2 and R3 , traffic characteristics information of three net- 
work doma ins. 

As an option compared to the above described network-wide ag- 
gregation for network domains, it is contemplated to perform a 
network domain related aggregation. Here, aggregated traffic 
characteristic information per network domain is included in 
the messages transmitted in direction to the server. As a re- 
sult, with reference to Fig. 6, the server receives a message 
including the traffic characteristics information of the 
RESV*!- and RESV* 2 -messages, of the RESV* 3 - and RESV* 4 - 
messages, and the RESV* a ( 2 - and RESV* 3 , 4 -messages. 

Pre-reservation of network resources 

As explained above, RSVP resource reservations for a network 
or network domains are obtained by transmitting a respective 
ADSPEC-information comprised by a PATH-message. The ADSPEC- 
information is received by the network or the network domains, 
and especially the routers thereof, to determine the level of 
resource reservation required for a desired server-client com- 
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municat ion/ service quality. For allocating the reserved re- 
sources, the routers utilize a RESV-message transmitted from 
the client to allocate the necessary resources. In particular, 
RSVP-routers along the upstream path (i.e. in a communication 
5 direction towards a server) receiving RESV-message (s) utilize 
an admission control to authenticate respective resource re- 
quest and allocate necessary resources. If a router can not 
provide the requested resources (e.g. due to a lack of re- 
sources or authorization failures) , the router returns an er- 
10 ror message back to the client. If the resource request (s) can 
be satisfied, the respective router sends the respective RESV- 
message (s) upstream to the next router. 

For example in the case of a multicasting RSVP system, the 
15 following procedure of pre-reserving resources prevents unnec- 
essary resource reservations downstream from the server to the 
client and that e.g. a router close to the server can not pro- 
vide the required resources for allocation resulting in error 
messages sent to the client. A particular effect decreasing 
20 the communication/ service quality (e.g. communication trans- 
mission time) of such error messages sent back to the client 
is the release of allocated resources previously allocated by 
routers arranged between the error message sending router and 
the client. Further, correct and proper processing of such er- 
25 ror messages generated by different clients is complicated. 

The pre-reservation mechanism shown in Fig. 7 is enabled by 
the modification of the RSVP as described above. Beside the 
extension of the RSVP-messages transmitted from the server and 
30 the client, as detailed above, the PATH-message of the server 
is extended by a pre-reservation request. In Fig. 7, this ex- 
tension is indicated by the index "°" . The pre-reservation re- 
quest of the server specifies a resource type and the extend 
thereof to be reserved. 
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Comparable thereto, the client extends the extended RESV*-r 
message generated as explained above by a allocation request. 
Here, the index "°" is indicative of the allocation request. 

Referring to the example shown in Fig. 7, the server requests 
12 units of the specified resource type. Upon receiving the 
PATH°-message, the router Rl determines whether he can satisfy 
this request. Since the router Rl is able to provide the re- 
quested resources, the router Rl pre-reserves 12 units. 

The router Rl generates a PATH 0 ' -message extended by the above 
traffic characteristics information and the pre-reservation 
request. Although router R2 can only provide 8 units, which 
are reserved, the PATH 0 -message of router R2 is generated 
and transmitted to the router R3 . In contrast thereto, accord- 
ing to a conventional RSVP system, an error message would be 
returned to a client in response to a RESV-message thereof to 
indicate that a resource request can not be satisfied. 


20 The router R3 is able to provide 4 units of the requested re- 
source and reserved the same. Again, no error message is re- 
turned to the server, but a PATH 0 ' * -message is communicated to 
the client. 


Therefore, the client gets a communication/service resource 
request which is agreed and confirmed by all routers Rl, R2 
and R3 between the server and the client. 


Upon confirmation of the received resource request, the client 
30 generates a RESV* °-message extended as the explained above and 
including an allocation request. Since the received resource 
request indicates that 4 units of the requested resource type 
can be provided for the overall communications connection be- 
tween the server and the client, the allocation request gener- 
35 ated by the client indicates that four units of the requested 
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resource type are needed and should be allocated by the 
routers Rl , R2 and R3 . 

While transmitting the RESV*°»-, RESV* ° ' ' - and RESV* ° » » ' - 
5 messages, which include the above explained extensions by the 
routers Rl, R2 and R3 and the allocation reguest of the cli- 
ent, each of the routers Rl, R2 and R3 allocate 4 units of the 
requested resource type and release the previously reserved 
units actually not needed. 

10 

Further, messages transmitted upstream from the client and 
routers Rl, R2 , and R3 (e.g. RESV* 0 '-, RESV* 0 ' '-, and 
RESV* 0 -messages) can include information specifying that 
all pre-reserved and/ or pre-al located resources remain re- 
15 served and/or allocated, or that a maximum or minimum pre- 
reserved and/or pre-allocated resources remain reserved and/or 
allocated. This approach still results in an improved QoS. 

The pre-reservation/pre-allocation mechanism can be used to 
20 ensure that clients and/or servers having a high(er) priority 
will be provided with required resources. 

Additionally, it is contemplated that the server can extend 
his RSVP-message by information (e.g. in form of an indicator) 
25 representing an upper and/ lower limit of resources to be re- 
reserved (maximum/minimum resource reservation indicator) . 

Since some of the pre-reserved resources in response to a 
PATH°-message may be released upon the reception of the re- 

30 spective RESV* °-message, such resources could be partly used 
by an allocation request having a higher priority. As set 
forth above, an indicator in each router is used to specify 
whether a resource reservation is an actual resource alloca- 
tion in response to a RESV-message or a pre-reservation in re- 

35 sponse to a PATH-message . To specify the amount of pre- 
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reserved resources which can be used to satisfy a higher pri- 
ority resource allocation, the above minimum resource reserva- 
tion indicator can be used. The amount of resources above the 
limit defined by this indicator can be optionally used to ful- 
fill a higher priority resource allocation request related to 
a different PATH-request . As a result, a communication connec- 
tion related to the higher priority resource allocation re- 
quest can be setup faster since these resources have already 
been reserved and no separate reservation is required. 

Comparable to the maximum/ minimum indicators of the PATH°- 
message, the RESV* ° -message can specify a minimum and/or a 
maximum of resources (types) to be allocated. For example, the 
RESV*°-message specifies said all routers should provide the 
same minimum bandwidth, such that all bandwidth related re- 
sources of the routers unnecessarily reserved are released. 

Especially the utilization of minimum resource indicators for 
the PATH ° — and RESV* "-messages guaranties said servers and/or 
clients having a higher priority are provided the required re- 
sources, since related higher priority resource requests can 
be fulfilled and are not blocked by a reservation of re- 
sources . 
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CLAIMS ^ 

30. Nov. 2000 

1. A method for improving resource reservations and alloca- 
5 tions in a network operated by a given signaling message pro- 
tocol, the method comprising: 

generating a sender signal (PATH-message) according to the 
given protocol including sender traffic characteristics infor- 
mation of a sender (server) , and 
10 - transmitting the server signal (PATH-message) via at least 
one network, 
characterized by 

including network traffic characteristics information into 
the sender signal (PATH-message) while being transmitted to 
15 obtain an extended sender signal (PATH 1 -message) , the network 
traffic characteristics information being indicative of traf- 
fic characteristics of the network, and 

reserving and/or allocating resources of the network in 
dependence of the network traffic characteristics information. 

20 

2. The method according to claim 1, comprising: 

receiving the extended sender signal (PATH ' -message) by a 
receiver (client) , 

generating a receiver signal (RESV-message) according to 
25 the given protocol including receiver traffic characteristics 
information being indicative of traffic characteristics of the 
receiver (client) , 

including the network traffic characteristics information 
into the receiver signal (RESV-message) to obtain an extended 
30 receiver signal (RESV* -message) , and 

- reserving and/or allocating resources of the network in 
dependence of the network traffic characteristics information 
and the receiver traffic characteristics information. 
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3. The method according to claim 2, comprising: 

transmitting the extended receiver signal (RESV*-message) 

to the sender (server) via the at least one network, 

updating the extended receiver signal (RESV*-message) by 

including actual network traffic characteristics information 

while transmitting the receiver signal (RESV*-message) , and 

reserving and/or allocating resources of the at least one 

network in dependence of the updated extended receiver signal 

(RESV* 1 -message) . 


4. The method according to one of the preceding claims, com- 
prising: 

transmitting the extended sender signal (PATH 1 -message) 
and/or the extended receiver signal (RESV*-message) and/or the 
updated extended receiver signal (RESV* ' -message) via at least 
one router (Rl, R2 , R3) of the at least one network, and 

including and/or updating the network traffics character- 
istics information by including and/or updating information 
being indicative of traffic characteristics of the at least 
20 one router (Rl, R2 , R3) . 

5. The method according to one of the preceding claims, 
wherein : 

- the sender (server) reserves and/or allocates network re- 
25 sources in dependence from the signal (RESV* -message, RESV* * - 
message) received from the at least one network. 

6. The method according to one of the preceding claims, 
wherein : 

30 - the receiver (client) receives and/or allocates network 

resources in dependence of the received extended sender signal 
(PATH • -message) . 
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7. The method according to one of the claims 4 to 6 , wherein 
the at least one router (Rl, R2 , R3) reserves and/or allo- 
cates its resources in dependence of the received signal 

(PATH ' -message , RESV*-message, RESV* ' -message) received from 
the at least one network. 

8. The method according to one of the preceding claims, com- 
prising: 

- including reservation and/or allocation information into 
the sender signal (PATH-message) according to the given proto- 
col, the reservation and/or allocation information being in- 
dicative of network resources to be pre-reserved and/or pre-al- 
located, and 

pre-reserving and/or pre-allocating network resources in 
dependence of the reservation and/or allocation information. 

9. The method according to claim 8, comprising: 

- including actual reservation and/or allocation information 
into the extended sender signal (PATH 0 1 -message) including the 
reservation and/or allocation information, the actual reserva- 
tion and/or allocation information being indicative of network 
resources actually pre-reserved and/or pre-allocated. 

10. The method according to claim 9, wherein: 

the at least one router (Rl, R2 , R3) reserves and/or allo- 
cates available resources thereof in dependence of the reser- 
vation and/or allocation information of the sender (server) , 
and 

- includes the actual reservation and/or allocation informa- 
tion corresponding to the actually pre-reserved and/or pre- 
allocated router resources. 
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11. The method according to one of the claims 8 to 10, 
wherein: 

the receiver (client) includes a reservation and/or allo- 
cation request into the extended receiver signal (RESV*- 
5 message) in dependence of the received actual reservation 

and/or allocation information, the reservation and/or alloca- 
tion request being indicative of network resources to be used 
for communication with the sender (server) . 

10 12. The method according to claim 11, comprising: 

reserving and/or allocating network resources in depend- 
ence of the reservation and/or allocation request in the ex- 
tended receiver signal (RESV* °-message) and/or the updated ex- 
tended receiver signal (RESV* ° 1 -message) . 

15 

13. The method according to claim 12, wherein: 

the at least one router (Rl, R2 , R3) reserves and/or allo- 
cates pre-reserved and/or pre-allocated router resources in 
dependence of the reservation and/ or allocation request in the 
20 signal (RESV* "-message, RESV * ° 1 —message) transmitted from the 
receiver (client) . 


14. The method of claim 12 or 13, wherein: 
pre-reserved and/or pre-allocated network resources ex- 

25 ceeding the reservation and/or allocation request of the re- 
ceiver (client) are released. 

15. A method according to claim 14, wherein: 

the at least one router (Rl, R2 , R3) releases its pre- 
30 reserved and/or pre-allocated resources in dependence of the 
reservation and/or allocation request in the signal (RESV*°- 
message, RESV* ° ' -message) transmitted from the receiver (cli 
ent) . 
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16. A method according to one of the claims 11 to 15, wherein: 
the receiver (client) includes information into the ex- 
tended receiver signal (RESV* -message) , the information being 
indicative of a maximum or a minimum of the pre-reserved 

5 and/or pre-allocated network resources to remain reserved 
and/or allocated. 

17. The method of claim 16, wherein: 

pre-reserved and/ or pre-allocated network resources remain 
10 reserved and/or allocated in dependence of the information in- 
cluded into the extended receiver signal (RESV*-message) being 
indicative of the maximum or the minimum network resources to 
remain reserved and or allocated. 

15 18. The method according to claim 17, wherein: 

the at least on router (Rl, R2 , R3) maintains its pre- 
reserved and/or pre-allocated resources in dependence of the 
receiver information being indicative of the maximum or the 
minimum of network resources to remain reserved and/or allo- 

20 cated . 

19. The method according to one of the preceding claims, 
wherein : 

the signals (PATH-message, PATH • -message , RESV-message, 
25 RESV* -message, RESV* —message, PATH 0 ' -message, RESV*°- 

message, RESV -message) include information being indicative 
whether a resource reservation and/or allocation is performed 
for a message transmitted in a direction to the receiver (cli- 
ent) and/or for a message transmitted to the sender (server) . 

30 

20. The method according to claim 19, wherein: 

the information included into the transmitted signals com- 
prise an indicator specifying a minimum of reguired network 
resources . 

35 
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21. The method according to claim 20, wherein: 

_ pre-reserved and/or pre-allocated network resources ex- 
ceeding network resources specified by the indicator are used 
for at least one network resource request having a higher pri- 
5 ority. 

22. The method according to one of the preceding claims, 
wherein: 

- the given signaling message protocol is the resource res- 
10 ervation protocol (RSVP) , 

the sender signal (PATH-message) is the PATH-message of 
the resource reservation protocol (RSVP) , and 

the receiver signal (RESV-message) is the RESV-message of 
the resource reservation protocol (RSVP) . 

15 

23. The method according to one of the preceding claims, 
wherein : 

- the method is utilized in a network serving a single-cli- 
ent and/or a multi-client application. 

20 

24. The method according to claim 23, wherein: 

the signals (PATH-message, PATH • -message , PATH 0 ' -message) 
transmitted to the client (s) are transmitted by utilizing a 
multicasting transmission. 

25 

25. The method according to claim 23 or 24, wherein: 

the signals (RESV-message, RESV*-message, . RESV* ' -message, 
RESV* °-message, RESV* ° ' -message) transmitted to the sender 
(server) are transmitted by a utilization of an inverse multi- 
30 casting transmission. 

26. The method according to claim 24 or 25, wherein: 

an aggregation of information included into the signals 
transmitted via the network is performed with the respect to 
35 the at least one network and/or components thereof. 
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27. A network system utilizing a given signaling message pro- 
tocol for network resource reservations and allocations, com- 
prising : 

- a sender (server) , 

- a receiver (client) , and 

- at least one network for connecting the sender (server) 
and the receiver (client) , wherein 

the sender (server) is adapted to be operated by the 
method according to one of the claims 1 to 20. 

28. The network system according to claim 27, wherein: 
the receiver (client) is adapted to be operated by the 

method according to one of the claims 1 to 26. 

29. The network system according to claim 27 or 28, compris- 
ing: 

at least one router (Rl, R2 , R3 ) of the at least one net- 
work, the at least one router (Rl, R2 , R3) being adapted to be 
operated by the method according to one of the claims 4 to 26. 

30. The network system according to one of the claims 27 to 
29, wherein: 

- the given signaling message protocol is the resource res- 
ervation protocol (RSVP) . 
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ABSTRACT 


The present invention provides a method for operating a net- 
work system and a network system operated correspondingly for 
5 improving network resource reservations and allocations. In- 
formation included in signaling messages of a given protocol, 
like the resource reservation protocol (RSVP) , which do not 
provide information about the actual communications status in 
the network. According to the invention, information concern- 

10 ing the communications/service quality of the network are col- 
lected from allover the network. In particular, such informa- 
tion is collected from all network domains and their routers, 
respectively. The collected information is communicated in the 
network by extending the signaling messages obtained on the 

15 basis of the given protocol. Utilizing the collected informa- 
tion, service quality negotiations between a server and its 
client are improved. This improvement can be achieved for net- 
work systems comprising a network domain serving a single cli- 
ent, and multicasting networks. Furthermore, the present in- 

20 vention provides a solution for pre-reservation of network re- 
sources which avoids an unnecessary reservation of network re- 
sources and a waste of network resources for subsequent re- 
source allocations. 


25 


7227 


□ 



This Page Blank (uspto) 


EPO- Munich 
22 

3 ft Nov. 2000 



□ 



30-11-2000 


mwsmi 


HIS 





■Printed 30-10 2001 ] 


[o6l26227] 




This Page Blank (uspto) 


